home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Network Supervisor's Toolkit
/
Network Supervisor's Toolkit.iso
/
novell
/
nw386
/
odi-10.386
< prev
next >
Wrap
Text File
|
1996-07-10
|
16KB
|
355 lines
Chapter 10
Open Data-Link Interface
Open Data-Link Interface specifications allow media-
independent and protocol-independent communications.
Because of this, the specifications, along with the
Streams environment and NLMs, make NetWare 386 a true
server platform on which you can build a customized
system. This section includes the following discussions:
■ Layers
■ Packet Transmission
■ Protocol ID Information
Layers
With the Open Data-Link specifications, NetWare 386
supports a large number of LAN adapters, and can receive
or send a variety of communication protocols on the same
wire concurrently (i.e. IPX/SPX, TCP/IP, AppleTalk). The
implementation of Open Data-Link Interface specifications
is perhaps best explained as several layers through which
communications arriving at or departing from the server,
bridge, or workstation must travel. The layers, as shown
in the following graphic, include the LAN adapter and
MultiLink Interface Driver layer, the Link Support Layer,
and the Protocol Stack layer. From the protocol stack
layer, communication packets can access the NetWare OS.
┌───────────────────────────────────────────────┐
│ │
│ NetWare 386 OS Services │
│ │
└───────────────────────────────────────────────┘
┌────────┐ ┌────────┐
│ │ │ │
│NCP/IPX │ │ Apple │
│ │ │ │
│Protocol│ │Protocol│
│ Stack │ │ Stack │
└────────┘ └────────┘
┌──────────────────────────────────────────────┐
│ │
│ Link Support Layer (LSL) │
│ │
└──────────────────────────────────────────────┘
┌─────────┐ ┌────────┐ ┌────────┐ ┌─────────┐
│ │ │ │ │ │ │ │
│EtherTalk│ │ NE2000 │ │ RX-Net │ │TokenRing│
│ │ │ │ │ │ │ │
│ MLID │ │ MLID │ │ MLID │ │ MLID │
│ │ │ │ │ │ │ │
└─────────┘ └────────┘ └────────┘ └─────────┘
MultiLink Interface Drivers (MLID)
┌──────┐ ┌─────┐ ┌─────┐ ┌──────┐
┌┴─────┐│ ┌┴────┐│ ┌┴────┐│ ┌┴─────┐│
┌┴─────┐├┘ ┌┴────┐├┘ ┌┴────┐├┘ │ ├┘
┌┴─────┐├┘ ┌┴────┐├┘ ┌┴────┐├┘ └──────┘
│ ├┘ │ ├┘ │ ├┘
└──────┘ └─────┘ └─────┘
LAN Adapters
Packet Transmission
The role of Open Data-Link Interface specifications can
be further illustrated through the process of packet
transmission. The following is an explanation of packet
transmission on a network, first without Open Data-Link
Interface specifications, and then with the
specifications.
Without the Open Data-Link Interface specifications (on
a NetWare 286 network), a workstation LAN adapter sends
an IPX packet to another workstation where it is received
by a LAN adapter. The adapter's LAN driver passes the
packet to the workstation's IPX, which either passes it
to higher levels or routes it down through another LAN
adapter to another network. This process permits only
one protocol packet per media at a time because the LAN
adapter driver is written to identify and accept only a
specific type of packet, whether an IPX packet, an
AppleTalk packet, a TCP/IP packet, etc.
NetWare 386's implementation of Open Data-Link Interface
specifications, however, supports a number of protocols
on each media or LAN adapter. On a NetWare 386 network,
with Open Data-Link Interface specifications, a
workstation LAN adapter sends any kind of packet (IPX,
AppleTalk, TCP/IP, etc) to another workstation where it
is received by a LAN adapter. The LAN driver for that
adapter, unlike the LAN driver for the 286 network, can
accept any type packet. Thus, it is called a MultiLink
Interface Driver (MLID). This MLID passes the packet to
the next layer in the Open Data-Link Interface, the Link
Support Layer (LSL).
The Link Support Layer (LSL) is responsible for
identifying the type of packet it receives and passing
it to the appropriate protocol in the next higher layer.
This next higher layer is called the Protocol Stack
layer, and it contains any number of protocol stacks such
as IPX, AppleTalk, and TCP/IP. Once a communication
packet arrives at its specified protocol stack, it is
either passed to higher levels or routed back down
through the LSL to an MLID and to a specified LAN adapter
which represents another network.MLID
As the explanation on packet transmission points out, the
NetWare 386 MLID is different from a NetWare 286 driver.
An MLID accepts multiple protocol packets rather than
just one as 286 LAN drivers do. When it receives a
packet the MLID makes no effort to interpret it, but
simply copies identification information from the packet
into a receive ECB and passes the ECB to the LSL.
Likewise, when sending out a packet, the MLID simply
copies identification information from a send ECB into
the packet and sends it out.
LSL
The Link Support Layer (LSL) is a support and a link
through which multiple protocol packets travel as they
go from the LAN adapter with its accompanying MLID to a
designated protocol stack. The LSL acts as a type of
switch board to route packets between LAN adapters with
their MLIDs and Protocol Stacks. As such, it must
contain information about these two layers. Thus, the
LSL contains a data segment (OSData) which maintains LAN
adapter information, Protocol Stack information, binding
information, and ECB information.
The LSL assigns each LAN adapter a logical number and
maintains information about each LAN adapter. This
information is registered with the LSL at load time.
It is also important to emphasize that the LSL never
recognizes an MLID as an entity that controls one or more
LAN adapters. Instead, the LSL sees beneath it only LAN
adapters, associating with each adapter a block of data,
a send routine, and a control routine. Although LAN
adapters may have the same send and control routines
(driven by the same driver), this does not matter to the
LSL since each LAN adapter always has its own block of
data.
The LSL also assigns each protocol stack a logical
protocol stack number (up to 16 stacks are supported) and
maintains information about each one. As with the LAN
adapter information, this protocol stack information is
registered with the LSL at load time.
In addition to the information about the LAN adapters
below it and the protocol stacks above it, the LSL needs
information from the Event Control Blocks (ECBs) that
come from either direction, depending on whether they are
send or receive ECBs. The LSL uses the packet ID
information in the ECBs and the other information about
LAN adapters below it and protocol stacks above it to
route packets from LAN adapters to protocol stacks and
from protocol stacks to LAN adapters.And finally, the LSL must also have a set of routines to
support the drivers that are below and a set of routines
for the protocol stacks above. Using this information,
the LSL is able to act as a switch board coordinating
protocol stack/MLID interaction and packet movement
within the server. The Open Data-Link Interface
architecture, including the information in the LSL is
shown in the following graphic:
┌───────────────────────────────────────────────┐
│ │
│ NetWare 386 OS Services │
│ │
└───────────────────────────────────────────────┘
┌────────┐ ┌────────┐
│ │ │ │
│NCP/IPX │ │ Apple │
│ │ │ │
│Protocol│ │Protocol│
│ Stack │ │ Stack │
└────────┘ └────────┘
┌──────────────────────────────────────────────┐
│ Send ECB Info Protocol Stack Info │
│ and Support Routines │
│ │
│ LSL │
│ │
│ │
│ LAN Adapter Info and │
│ MLID Support Routines Receive ECB Info │
└──────────────────────────────────────────────┘
..................
┌────────────────┐ .
┌────┴───────────┐ 5 │ .
┌────┴───────────┐ 4 │ │.....
┌────┴───────────┐ 3 │ ├────┘
┌────┴───────────┐ 2 │ ├────┘
┌────┴───────────┐ 1 │ ├────┘
│ LAN Adapter 0 │ ├────┘
│ ├────┘
└────────────────┘
Each network station (server, bridge, OS/2 workstation,
DOS workstation) has its own implementation of an LSL.
Novell has created an LSL for the NetWare 386 server and
the OS/2 workstation, and plans to create Link Support
Layers for other workstation operating systems as well.
Currently, the NetWare 386 server LSL supports up to
eight MLIDs and up to 16 protocol stacks.The following graphic illustrates two different types of
communication packets entering a NetWare 386 server on
an Ethernet adapter.
┌───────────────────────────────────────────────┐
│ │
│ NetWare 386 OS Services │
│ │
└───────────────────────────────────────────────┘
┌────────┐ ┌────────┐
│ │ │ │
│NCP/IPX │ │ Apple │
│ │ │ │
│Protocol│ │Protocol│
│ Stack │ │ Stack │
└────────┘ └────────┘
┌──────────────────────────────────────────────┐
│ │
│ LSL │
│ │
└──────────────────────────────────────────────┘
┌─────────┐ ┌────────┐ ┌────────┐ ┌──────────┐
│ │ │ │ │ │ │ │
│EtherTalk│ │ NE2000 │ │ RX-NET │ │Token Ring│
│ │ │ │ │ │ │ │
│ MLID │ │ MLID │ │ MLID │ │ MLID │
│ │ │ │ │ │ │ │
└─────────┘ └────────┘ └────────┘ └──────────┘
┌──────┐ ┌─────┐ ┌─────┐ ┌──────┐
┌┴─────┐│ ┌┴────┐│ ┌┴────┐│ ┌┴─────┐│
┌┴─────┐├┘ ┌┴────┐├┘ ┌┴────┐├┘ │ ├┘
┌┴─────┐├┘ ┌┴────┐├┘ ┌┴────┐├┘ └──────┘
┌─────────┤ ├┘ │ ├┘ │ ├┘
│ └──────┘ └─────┘ └─────┘
│ LAN Adapters
│
│
│ ┌───┬───┬───┐ ┌───┬───┬───┐
│ │ 8 │ │ D │ │ 8 │ A │ D │
│ │ 1 │ I │ a │ │ 0 │ p │ a │
└───────┤ 3 │ P │ t ├────────┤ 9 │ p │ t ├────────┐
│ 7 │ X │ a │ │ B │ l │ a │ │
│ h │ │ │ │ h │ e │ │ │
└───┴───┴───┘ └───┴───┴───┘ │
Packet Packet │
Protocol ID Information
Every packet on a network that supports multiple
protocols is made up of the following components:
■ A communications protocol packet such as IPX,
TCP/IP, or Apple.
■ A media envelope
■ A globally administered value (1 to 6 bytes) called
a Protocol ID (PID), located inside the media
envelope.
As its name indicates, the PID that is located in every
packet is a label that identifies two things about the
packet:
■ The packet contains a certain communication protocol
header.
■ The packet contains a certain envelope frame.
As shown in the following graphic for example, an IPX
header and an Ethernet II envelope have a PID of 8137h.
An AFP header and an Ethernet II envelope have a PID of
FAh. However, another protocol packet on another medium
(for example, TCP/IP on ARCNET) might have the identical
PID of 8137h or FAh. PID values are not unique across
all media. The LSL uses the PID value to route incoming
packets to the proper protocol stack.
Although
most packets contain a PID value that allows the LSL to
route the packet to the correct destination protocol
stack, some packets do not. For example, networks
sending packets with 802.3 envelope headers do not
contain a PID field since those networks support only one
type of communication protocol. In these cases, MLIDs
should be configured to stamp receive ECBs with a PID
value instead of copying the value from the incoming
packet. The structure for the Protocol ID is shown
below.
---------------------------------
Protocol ID Structure
ProtocolIDStructure struc
Link dd ?
MediaID dw ?
ProtocolID db 6 dup (?)
PSLogicalNumber dd ?
ProtocolIDStructure ends
---------------------------------